If your site or data was lost and your hosting company claims they had off-site backups, you can gather objective evidence to confirm or refute that claim. This tutorial walks you through a practical, forensically minded approach: what to ask for, how to validate logs, what common false claims look like, and advanced techniques for preserving and presenting proof. Follow these steps and you’ll have a defensible record in a month or less.
Before You Start: Documents and Tools to Build Your Backup Failure Case
Collecting the right items up front speeds the process and prevents spoliation of evidence. Prepare these documents and tools before you contact your host.
- Time window - Define clear start and end dates for the incident and any suspected backup activity (for example, 2025-04-01 to 2025-04-15). Account details - Hosting account ID, billing records, domain names, server names, and any service-level agreement (SLA) language on backups. Communications - Copies of support tickets, emails, and chat transcripts related to the incident. Local copies - Any local backups, database dumps, or screenshots you already have. Tools - A secure workstation, checksum tool (sha256sum), log parsing tools (grep, awk), and a storage location to save confirmed evidence. Forensic preservation plan - A simple chain-of-custody form and hashing procedure to prove data integrity.
Who to talk to first
Start with the account owner and the support channel used most recently. If possible, escalate to an operations or engineering contact who can access system logs. Keep all communications in writing and request formal preservation of evidence if you suspect the provider may delete logs.
Your Complete Investigation Roadmap: 9 Steps to Prove Missing Off-Site Backups
Follow these steps in order. Each step includes the specific logs or artifacts to livingproofmag.com request, how to verify them, and what to do if the host refuses.
Step 1 - Make a preservation request
Send a written preservation request that asks the host to retain all relevant logs and to not modify or delete them. Example language: "Please preserve and provide copies of all logs and artifacts covering [start] to [end], including system logs, backup job logs, backup transfer logs, and storage metadata. Preserve originals and do not alter timestamps." Ask for an acknowledgment and a timestamped confirmation.
Step 2 - Request backup job logs and configuration files
Ask for backup software logs and configuration files. Specify names and locations where possible. Typical items:
- /var/log/rsync.log, /var/log/duplicity.log, /var/log/borg.log /etc/cron.d/* and crontab entries for root and backup users Backup configs: /etc/duplicity/conf, /etc/bacula/bacula-dir.conf, /etc/borgmatic.conf Backup job definitions in control panels (cPanel backups, Plesk backup tasks)
Ask for the raw log files, not just parsed summaries.
Step 3 - Request transfer and storage logs that show off-site movement
Off-site backups leave transfer traces. Request:
- SFTP/SCP logs showing file uploads (sshd logs often include subsystem usage) rsync --log-file outputs and rsync daemon logs Cloud provider logs: S3 access logs, Google Cloud Storage object logs, Azure Blob storage access logs Firewall or network gateway logs showing outbound connections to backup endpoints Object-store metadata: list of objects with LastModified, Size, ETag (checksums)
Step 4 - Ask for backup verification reports and restore tests
Many providers run verification and test restores. Request:
- Backup verification reports showing checksum validation Records of restore drills or test restores and their results Automated integrity reports from backup tools
Step 5 - Collect storage inventory and retention policies
Get records that show where backups were stored and how long they were kept:
- Bucket and container lists, lifecycle rules, and retention settings Snapshot lists for block storage and VM snapshots with timestamps Media rotation logs for tape libraries or offline archival systems
Step 6 - Pull system and audit logs
System-level logs help corroborate backup activity:
- /var/log/syslog, /var/log/messages, journalctl output auditd logs for file access and process execution Database logs showing dumps (mysqldump timestamps, PostgreSQL pg_dump entries)
Step 7 - Request chain-of-custody and signed statements
Ask the host to provide a signed statement from the administrator responsible for backups, certifying the completeness of the logs and when they were produced. If possible, ask them to provide SHA-256 hashes of the originals and sign those hashes.
Step 8 - Verify integrity locally
When you receive files, compute SHA-256 hashes and compare with hashes provided by the host. Commands you can run:
sha256sum received-log-file.log > received-log-file.log.sha256Keep a record of the hash, filename, and timestamp. If you find gaps, note the exact missing timestamps and file names.
Step 9 - Compile a clear, time-stamped exhibit
Produce a timeline that maps the incident to the logs. Include raw log snippets, checksums, metadata from object storage, and the host's signed statement. This exhibit is what you will present to support teams, regulators, or in legal proceedings.
Avoid These 7 Evidence Mistakes That Undermine Backup Claims
Even small errors can make your case weaker. Watch out for these common missteps.
- Accepting summaries only - Host-provided summaries can hide gaps. Always ask for raw logs and metadata. Missing the time window - If your request covers the wrong dates, critical entries could be excluded. No hashes - Without cryptographic hashes, the integrity of logs is harder to prove. Failing to preserve local evidence - If you later need to compare, local backups you kept must be intact and hashed. Relying on human memory - Pair assertions with timestamps and files, not recollections. Overlooking metadata - File sizes, LastModified, and ETag values often expose inconsistencies. Not escalating - If the host refuses, escalate to an engineering contact or consider legal preservation letters.
Pro Forensics Techniques: Advanced Log Analysis and Preservation Tactics
These advanced tactics are for when you need airtight proof or suspect intentional tampering.
Cross-check independent sources
Compare host logs with third-party data: DNS query logs, CDN logs, payment gateway logs, or your own monitoring alerts. Consistent discrepancies across sources strengthen the case against the host's claim.
Checksum and snapshot comparison thought experiment
Imagine the host claims they backed up a 10GB database nightly. If you can obtain the cloud storage object list with ETag values across dates, you can compare object ETags or provided checksums to show whether the same content was uploaded repeatedly or not. If ETags are missing or object sizes don't change despite new data, the "backup" may be a placeholder operation rather than a real copy.
Forensic timeline reconstruction
Reconstruct a timeline from disparate logs: web access logs show data creation at 02:00, backup log shows backup at 03:00, object-store metadata shows no new object at 03:15. That gap indicates the backup job did not upload the new data. Use automated scripts to extract and align timestamps from each log source.
Use immutable timestamping
For future incidents, consider adopting immutable, externally verifiable timestamps: have your monitoring system write a hash of critical files to an external timestamping service or blockchain-style notarization service. If a dispute happens later, the notarized hashes prove the file state at a given time.
Simulate a hostile scenario
Thought experiment: An attacker gained access and deleted both live data and local backups. What would remain? Ask the host for tape rotation logs, off-site pickup receipts, and storage provider logs that an attacker likely could not alter. If those are absent, it suggests no off-site copy existed to begin with.
When Your Host Pushes Back: Fixing Evidence Gaps and Next Steps
Hosts sometimes refuse to provide logs or claim logs were rotated away. Here are practical remedies and escalation paths.
- Preservation demand - Send a formal written preservation request and ask them to acknowledge. This increases legal risk for them if they later delete evidence. Request metadata only - If the host resists giving raw logs, ask for minimal metadata lists (object names, sizes, timestamps) that are harder to deny. Third-party audit - Propose an independent auditor to inspect systems under an NDA. Many providers accept this if a dispute could impact liability. Regulator or contract route - If your SLA specifically promises off-site backups, cite the contract and request remediation or credits. Escalate to consumer protection or data protection authorities if necessary. Legal preservation letter - If imminent deletion is suspected, a lawyer can send a formal preservation letter. This often forces the provider to keep evidence. Hire a forensic expert - If stakes are high, bring in a digital forensics firm to handle acquisition and chain-of-custody professionally.
Sample escalation email snippet
"Per the account SLA and our prior communications, please preserve and produce all backup-related logs, transfer artifacts, and storage metadata for [start] to [end]. If you cannot produce raw logs, provide exact reasons and any available metadata (object names, sizes, timestamps). Please acknowledge receipt and preservation by [date/time]."
Final checklist and next steps
Run through this quick checklist before closing your investigation:
- Preservation request acknowledged and dated Raw backup logs and configuration files received Transfer and storage logs from off-site destinations received Hashes computed and matched to host-provided hashes Signed statement or chain-of-custody record from host Timeline exhibit prepared with supporting artifacts Escalation plan ready if gaps remain
With these materials in hand, you’ll be able to demonstrate, with timestamps and hashes, whether your host actually maintained off-site backups. If the provider did not, the same evidence will support remediation requests, compensation claims, or legal action.
Closing thought experiment
Picture two cases. In Case A, your host produces daily backup job logs, object metadata with matching checksums, and verification reports. In Case B, they produce only summary emails and a signed statement claiming backups existed. Which would you trust? Use that mental model when deciding whether to escalate. The technical artifacts are what prove or disprove the claim; summaries and statements alone rarely hold up under scrutiny.
If you need a ready-to-send preservation template or a prioritized list of logs tailored to your hosting environment (managed VPS, shared hosting, cloud provider), tell me the environment and incident dates and I’ll draft a custom request you can use immediately.